home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13533 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.2 KB
  1. Path: ix.netcom.com!netnews
  2. From: jdmorris@ix.netcom.com (Jason D. Morris)
  3. Newsgroups: comp.lang.c++,comp.lang.c,comp.object,comp.software-eng
  4. Subject: Re: Pointers are hacks in c++ (portablity hackers etc)
  5. Date: Tue, 26 Mar 1996 02:53:55 GMT
  6. Organization: Netcom
  7. Message-ID: <31575aa3.33876812@nntp.ix.netcom.com>
  8. References: <4ikb6kINN1is@mayne.ugrad.cs.ubc.ca> <DoI5Ao.AyJ@assip.csasyd.oz> <EJH.96Mar19163745@larry.gsfc.nasa.gov> <vpwa1m6wu.fsf_-_@jlbaker.async.csuohio.edu>
  9. NNTP-Posting-Host: pon-mi4-02.ix.netcom.com
  10. X-NETCOM-Date: Mon Mar 25  6:53:01 PM PST 1996
  11. X-Newsreader: Forte Agent .99d/32.182
  12.  
  13. >I'm posting because I think I see a disturbing trend in c++.
  14. >Programmers seem to have an unreasoning fear of pointers in general:
  15. >An stl object lives in exactly one container, exactly one auto_ptr
  16. >points at any object and reference counting mechanisms seem aimed at
  17. >efficiently giving you a private object rather than sharing an object
  18. >without leakage.  With these constructs, you can have only one
  19. >reference to a new'ed object, something I find antithetical to the
  20. >very notion of a pointer.
  21.  
  22. It's not a fear, per se, but rather an understanding of the havoc
  23. pointers can wreak.  There are really two issues concerning pointers,
  24. their use in the presence of exceptions (ensuring that allocated
  25. resources are properly allocated).  The use of pointers in
  26. class/function interfaces and who has ownership.  The first problem is
  27. addressed by the auto_ptr class.  The second is can be addressed by
  28. using references in interfaces rather than pointers.  When a reference
  29. is used, there is no question of ownership.  The caller *always*
  30. retains ownership and *always* is responsible for deallocating the
  31. resource.  The only time I can think of when a pointer is acceptable
  32. in an interface is when and object/function must retain a reference to
  33. another object and that reference has the ability to change.  I
  34. suppose one could consider pointers to functions as acceptable.
  35. Essentially, all other uses for pointers are best left to the internal
  36. implementation of and object/function where the maintainer of the
  37. object/function is aware of the details of the pointer's use and
  38. allocation/deallocation policy.
  39.  
  40. Jason
  41.  
  42.